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Abstract 

The  Common  Authentication  Protocol  Specification 
Language  (CAPSL)  is  a  high-level  language  for  apply¬ 
ing  formal  methods  to  the  security  analysis  of  crypto¬ 
graphic  protocols.  Lts  goal  is  to  permit  a  protocol  to 
be  specified  once  in  a  form  that  is  usable  as  an  inter¬ 
face  to  any  type  of  analysis  tool  or  technique,  given 
appropriate  translation  software.  This  paper  describes 
the  first  operational  CAPSL  translator  to  the  language 
used  by  the  NRL  Protocol  Analyzer  (NPA),  a  software 
tool  developed  specifically  for  the  analysis  of  crypto¬ 
graphic  protocols. 


1  Introduction 

The  past  few  years  have  seen  an  increasing  interest 
in  the  application  of  formal  methods  to  the  analysis 
of  cryptographic  protocols.  Here  are  the  reasons  for 
this  interest,  and  the  response  of  the  formal  methods 
community. 

1.1  Background 

It  is  well  known  that  protocols  for  exchanging  cryp¬ 
tographic  keys  over  data  networks  can  be  vulnerable 
to  a  class  of  attacks  in  which  an  intruder  can  intercept 
and  alter  messages  in  transit.  In  many  cases,  the  secu¬ 
rity  objective  of  a  protocol  can  be  subverted  without 
“cracking”  the  cryptosystem,  and  the  vulnerability  is 
referred  to  as  a  protocol  failure. 

The  abundance  of  failures  discovered  in  published 
protocols  led  to  the  development  of  formal  techniques 
for  their  security  analysis.  These  techniques  include 
the  use  of  goal-directed  state  search  tools  implemented 
in  Prolog,  the  application  of  general  purpose  specifi¬ 
cation  and  verification  tools,  and  a  specially-designed 


logic  of  belief,  An  outline  of  the  history  of  the  sub¬ 
ject  and  some  of  the  tools  used  can  be  found  in  [9], 
Recently,  search  tools  designed  for  hardware  model¬ 
checking  have  been  successfully  applied  in  this  area  as 
well,  such  as  [16]  and  related  work  mentioned  in  that 
paper.  Recent  work  in  inductive  techniques  was  stim¬ 
ulated  largely  by  Paulson  [20] .  A  current  survey  of  the 
area  may  be  found  in  [8] . 

It  became  evident  that  it  was  difficult  for  analysts 
other  than  the  developers  of  the  various  techniques  to 
apply  them.  One  reason  for  this  difficulty  is  that  the 
protocols  had  to  be  re-specified  formally  for  each  tech¬ 
nique,  and  it  was  not  easy  to  transform  the  published 
description  of  the  protocol  into  the  required  formal 
system.  Some  tool  developers  began  work  on  trans¬ 
lators  or  compilers  that  would  perform  the  transfor¬ 
mation  automatically.  The  input  to  any  such  trans¬ 
lator  still  requires  a  form  ally- defined  language,  but  it 
can  be  made  similar  to  the  message-oriented  protocol 
descriptions  that  are  typically  published  in  articles, 
books,  and  protocol  standards  documents.  A  transla¬ 
tor  can  also  supply  certain  “boilerplate”  material  that 
changes  little,  if  at  all,  from  one  analysis  to  the  next, 
such  as  the  specification  of  intruder  capabilities. 

This  kind  of  thinking  led  to  several  languages:  an 
early  version  of  CAPSL  [15];  ISL,  from  which  CAPSL 
borrowed  much  of  its  style,  supporting  an  application 
of  HOL  to  an  extension  of  the  GNY  logic  [2];  CASPER 
[10],  for  the  application  of  a  model-checker  FDR  based 
on  CSP  as  an  input  language;  and  Carlsen’s  “Standard 
Notation,”  from  which  per-process  CKT5  specifica¬ 
tions  were  generated  [6].  The  idea  of  making  CAPSL 
into  a  common  language  that  could  be  used  as  the 
input  format  for  any  formal  analysis  technique  was 
first  presented  at  the  1996  Isaac  Newton  Institute  Pro¬ 
gramme  on  Computer  Security,  Cryptology,  and  Cod¬ 
ing  Theory  at  Cambridge  University. 
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1.2  Implementation  Plan 

At  this  stage  in  the  implementation  of  CAPSL,  the 
language  has  a  draft  specification  in  the  form  of  a  tech¬ 
nical  report  and  a  more  recent  description  at  a  project 
web  site  [5].  The  long-range  plan  for  CAPSL  includes 
developing  an  intermediate  language  (CIL,  for  CAPSL 
intermediate  language) ,  so  that  a  single  compiler  from 
CAPSL  to  CIL  can  be  shared  by  all  users.  Each  tool 
will  then  need  a  translator  from  CIL  to  its  own  input 
language. 

At  present,  CIL  and  associated  tools  are  still  under 
development.  However,  it  was  felt  to  be  important  to 
test  the  idea  that  an  independently  designed  specifica¬ 
tion  language  could  be  used  to  support  a  pre-existing 
security  analysis  tool.  This  could  be  done  by  imple¬ 
menting  an  interim  translator  directly  from  CAPSL  to 
the  language  of  such  a  tool. 

The  first  experiment  along  these  lines  is  reported 
here:  to  develop  an  interface  for  CAPSL  to  the  Pro¬ 
tocol  Analyzer  developed  at  the  U.S.  Naval  Research 
Laboratory  (NRL). 

1.3  The  NRL  Protocol  Analyzer 

The  NRL  Protocol  Analyzer  (NPA)  is  an  interac¬ 
tive  program,  written  in  Prolog,  that  can  be  used  to 
assist  either  in  the  verification  of  security  properties 
or  in  the  detection  of  security  flaws.  It  has  been  used 
successfully  on  a  number  of  protocols  and  has  found 
unexpected  flaws  in  several.  It  is  currently  being  used 
to  analyze  the  Internet  Key  Exchange  Protocol  [12,  13] 
and  the  Secure  Electronics  Transactions  Protocol  [14], 
A  more  detailed  description  of  a  slightly  earlier  version 
of  the  Analyzer  than  the  one  discussed  in  this  paper, 
that  uses  a  somewhat  different  specification  language, 
may  be  found  in  [11],  The  current  specification  lan¬ 
guage  is  somewhat  more  high-level,  but  is  still  seman¬ 
tically  consistent  with  the  earlier  one. 

The  analyzer  requires  protocols  to  be  specified  as 
a  collection  of  rules  expressing  protocol  state  changes 
and  symbolic  reduction  axioms  characterizing  encryp¬ 
tion  operators.  These  rules  have  a  conditional  stat- 
ment  form  and  use  Prolog  syntax  for  individual  terms. 

In  order  to  provide  a  CAPSL  interface  for  the  an¬ 
alyzer,  it  was  necessary  to  write  a  translator  from 
CAPSL  to  the  analyzer  rule  language.  The  translation 
process  is  divided  into  stages:  (1)  parsing  the  CAPSL 
into  an  abstract  syntax  tree  and  symbol  table;  (2)  gen¬ 
erating  an  internal  semantic  representation,  including 
programs  for  each  party  in  the  protocol;  and  (3)  gener¬ 
ating  the  analyzer  rules.  The  translator  also  generates 
other  output  representations. 


The  CAPSL  translator  for  the  NPA  foreshadows 
the  future  universal  CAPSL  compiler  in  part,  since  the 
parsing  stage  and  the  internal  semantic  representation 
stage  have  essentially  the  same  structure  as  the  trans¬ 
portable  compiler,  and  only  the  last  stage  is  NPA- 
specific. 

1.4  Summary  of  This  Paper 

In  this  paper,  we  give  a  brief  taste  of  the  CAPSL 
language,  followed  by  a  description  of  the  analyzer  and 
its  specification  language,  with  some  observations  on 
how  the  latter  differs  from  CAPSL.  We  then  describe 
the  design  and  implementation  of  the  translator,  and 
finally  present  some  conclusions  and  lessons  learned. 

2  The  CAPSL  Language 

A  CAPSL  specification  has  three  kinds  of  speci¬ 
fication  units:  protocols,  types,  and  environments. 
A  protocol  specification  describes  a  protocol  or  sub¬ 
protocol.  A  type  specification  introduces  new  en¬ 
cryption  operators,  if  necessary.  (Type  specifications 
for  standard  encryption  operators  are  provided  au¬ 
tomatically.)  An  environment  specification  provides 
scenario-specific  details  to  set  up  an  analysis  session 
for  model  checkers  or  other  tools  that  need  them. 

A  protocol  specification  has  three  principal  parts: 
declarations,  messages  and  goals.  Rather  than  at¬ 
tempt  to  cover  the  language  in  full  here,  we  will  just 
convey  the  flavor  of  CAPSL  with  an  example. 

The  Otway-Rees  protocol  involves  two  communi¬ 
cating  parties  (initiator  and  responder)  and  a  key 
server.  The  initiator  sends  a  request  to  the  respon¬ 
der,  who  forwards  it  to  the  key  server.  The  key  server 
sends  two  copies  of  the  key  (one  encrypted  with  the 
initiator’s  master  key,  and  one  encrypted  with  the  re¬ 
sponder’s  master  key)  to  the  responder.  The  respon¬ 
der  forwards  the  initiator’s  copy  to  the  initiator. 

The  Otway-Rees  protocol  is  fairly  well  known  [19]; 
it  has  some  subtle  flaws  that  do  not  concern  us  here. 
We  give  the  informal  specification  of  the  Otway-Rees 
Protocol  first  below.  It  has  four  messages. 

1.  1  >  n  :  M,  A,  B,  {  V  u .  A / .  A,  B}Kas 

A  initiates  the  protocol  with  B.  It  sends  a  session 
identifier  M  along  with  a  certificate  encrypted 
with  a  master  key  it  shares  with  the  server  S. 
The  certificate  contains  a  nonce,  the  session  iden¬ 
tifier,  and  the  names  of  A  and  B.  In  this  protocol, 
a  nonce  is  a  key-sized  randomly-generated  value. 


2.  B  ^  S  :  M,  A,  B,  {Na,M,A,B}Kas, 
{Nb,M,  A,  B}Kbs 

B  forwards  the  certificate  to  S,  but  also  concocts  a 
similar  certificate  of  its  own,  in  which  it  includes 
its  own  nonce.  It  encrypts  this  certificate  with 
the  master  key  Kbs  that  it  shares  with  S. 

3.  S  -»  B  :  M,{Na,  Kab}kas,{Nb,Kab}kbs 

S  decrypts  the  certificates  and  checks  that  they 
have  the  same  identifier.  It  then  generates  a  ses¬ 
sion  key.  It  encrypts  the  key  together  with  A’s 
nonce  A T a  with  A’s  key,  and  the  key  together  with 
B\ s  nonce  with  B’s  key.  Both  results  are  sent  to 
B  together  with  M. 

4.  B  >  .1  :  M,  {Na,  I<ab}kas 

B  decrypts  its  certificate  and  checks  for  its  nonce. 
It  forwards  the  remaining  parts  of  the  message 
to  A.  A  decrypts  its  certificate  and  checks  for  its 
nonce. 

We  next  give  the  CAPSL  specification.  As  one 
can  see,  this  is  very  close  to  the  informal  specifica¬ 
tion,  the  main  difference  being  that  the  information 
given  between  the  lines  in  the  informal  text  is  sup¬ 
plied  formally  in  the  declaration  part  of  the  specifi¬ 
cation.  CAPSL  also  requires  a  formal  statement  of 
the  security  goals.  Functional  notation  is  used  here 
for  concatenation  (con)  and  encryption  (se),  although 
CAPSL  allows  the  use  of  the  bracket  notation  as  an 
option. 

PROTOCOL  Otway_Rees; 

VARIABLES 

A,  B,  S:  Principal; 

M:  Field,  FRESH; 

Na,  Nb:  Field,  FRESH,  CRYPTO; 

Kass,  Kbs:  Skey,  CRYPTO; 

Kab:  Skey,  CRYPTO,  FRESH; 

KeyTable (Principal) :  Skey; 

DENOTES 

Kass  =  KeyTable (A); 

Kbs  =  KeyTable (B); 

ASSUMPTIONS 

HOLDS  A:  A,  B,  S,  M,  Na,  Kass; 

HOLDS  B:  B,  S,  Nb,  Kbs; 

HOLDS  S:  S,  KeyTable,  Kab; 

MESSAGES 

1.  A  ->  B:  M,  A,  B, 

se(Kass,con(Na,  M,  A,  B)); 

2.  B  ->  S:  M,  A,  B, 

se(Kass,con(Na,  M,  A,  B)), 
se(Kbs,con(Nb,  M,  A,  B)); 


Kass  =  KeyTable (A); 

Kbs  =  KeyTable (B); 

3.  S  ->  B:  M, 

se(Kass,con(Na,  Kab)), 
se(Kbs,con(Nb,  Kab)); 

4.  B  ->  A:  M,  se(Kass,con(Na,  Kab)); 

GOALS 

SECRET  Kass:  A,  S; 

SECRET  Kbs:  B,  S; 

SECRET  Kab:  A,  B,  S; 

END; 

Some  of  the  declarations  are  just  type  declarations, 
and  others  reflect  concepts  peculiar  to  authentication 
protocol  design.  The  nonces,  for  example,  are  declared 
with  qualifications  of  FRESH  and  CRYPTO,  meaning,  re¬ 
spectively,  that  they  have  not  been  used  before  and 
that  they  are  unguessable.  These  two  properties  are 
separable,  since  some  protocols  use  nonces  that  are 
fresh  but  not  unguessable  (like  TCP  sequence  num¬ 
bers),  and  long-term  keys  are  unguessable  but  not 
fresh. 

The  variable  KeyTable  and  the  DENOTES  equations 
indicate  how  each  party  looks  up  the  public  key  of 
other  parties.  The  HOLDS  assumptions  show  which 
variables  are  known  initially  by  each  party.  The  secu¬ 
rity  objectives  stated  here  are  that  the  keys  are  shared 
secrets  between  A  and  B.  One  could  also  state  other 
objectives,  such  as  a  belief  by  B  that  A  holds  Kab 
at  the  conclusion  of  the  protocol  run,  which  would  be 
expressed  as  BELIEVES  B:  HOLDS  A:  KAB. 

The  use  of  Kass  instead  of  Kas  is  due  to  a  naming 
conflict  with  a  built-in  use  of  kas  as  a  key  agreement 
operator.  This  problem  is  avoidable  and  will  be  fixed. 

Note  that  in  the  MESSAGES  section  it  is  possible  to 
interleave  equations  indicating  tests  or  assignments 
between  messages.  It  is  also  possible  to  put  in  as¬ 
sertions  indicating  message  idealizations  or  intermedi¬ 
ate  goals.  Furthermore,  one  may  write  conditional 
statements  that  invoke  named  subprotocols,  using 
IF-THEN-ELSE  and  INCLUDE  constructs. 

3  The  NRL  Protocol  Analyzer 

The  NRL  Protocol  Analyzer  (NPA)  is  a  tool  for 
proving  security  properties  of  protocols  and  for  finding 
attacks  on  protocols  if  the  security  properties  do  not 
hold.  It  works  by  having  the  user  specify  an  insecure 
state:  the  translator  works  backwards  from  that  state 
in  an  attempt  to  find  a  path  starting  in  an  initial  state. 
Originally,  the  search  space  is  infinite:  the  user  reduces 
the  search  space  to  a  finite  one  by  proving  a  set  of 


lemmas.  The  formulation  and  proof  of  these  lemmas 
is  not  completely  automatic,  but  a  large  amount  of 
automatic  assistance  is  provided,  and  we  expect  to 
provide  more. 

The  model  behind  NPA  is  an  extension  of  the 
Dolev-Yao  model  [7] .  We  assume  that  the  participants 
in  the  protocol  are  communicating  in  a  network  under 
the  control  of  a  hostile  intruder.  The  intruder  has  the 
ability  to  read  all  message  traffic,  destroy  and  alter 
messages,  and  create  its  own  messages.  Since  all  mes¬ 
sages  pass  through  the  intruder’s  domain,  any  mes¬ 
sage  that  an  honest  participant  sees  can  be  assumed 
to  originate  from  the  intruder.  Thus  a  protocol  rule 
describes,  not  how  one  participant  sends  a  message 
in  response  to  another,  but  how  the  intruder  manip¬ 
ulates  the  system  to  produce  messages  by  inserting 
other  messages. 

Principals  participate  in  a  protocol  by  exchanging 
words.  Words  are  the  analyzer’s  alebraic  term  repre¬ 
sentations  of  message  fields.  They  are  created  out  of 
variables  (denoted  by  strings  beginning  with  a  capi¬ 
tal  letter),  atoms  (denoted  by  strings  beginning  with 
a  lower-case  letter),  and  function  symbols  that  take 
words  as  arguments.  The  result  of  applying  a  func¬ 
tion  symbol  to  a  word  or  set  of  words  is  represented 
by  the  function  symbol  together  with  those  words  as 
arguments.  Thus,  if  e  denotes  the  encryption  opera¬ 
tor,  the  word  e(K,  X)  denotes  the  result  of  encrypting 
message  A"  with  key  K. 

We  can  now  describe  what  an  NPA  specification 
looks  like.  A  specification  consists  of  several  parts, 
the  most  important  of  which  is  a  list  of  rules  (called 
protocol  rules )  describing  how  participants  send,  re¬ 
ceive,  and  process  messages.  A  protocol  rule  involves 
four  things:  words  that  are  input  or  learned  by  an 
intruder,  local  state  variables ,  local  counters  that  are 
incremented  each  time  a  protocol  rule  is  fired,  and 
event  statements  that  are  used  to  describe  the  action 
that  occurred  when  a  protocol  rule  was  fired. 

Each  protocol  participant  possesses  a  counter  rep¬ 
resenting  its  local  time.  It  is  initially  set  to  zero,  and 
is  incremented  by  one  every  time  a  protocol  rule  in 
which  it  is  involved  is  fired. 

If  A  is  an  honest  participant  in  a  protocol,  a  run 
of  the  protocol  local  to  A  is  defined  to  be  a  sequence 
of  state  changes  local  to  A  defined  by  the  protocol 
designer.  Each  such  state  change  defines  a  set  of  words 
produced  by  A  and  a  set  of  changes  to  A’s  internal 
state  variables.  A  run  local  to  A  is  identified  by  the 
value  of  A’s  counter  at  the  time  the  run  begins.  Any 
state  variable  local  to  that  run  is  identified  by  the  run’s 
identifier.  We  note  that  a  participant  may  participate 


in  two  or  more  runs  concurrently.  Since  they  will  be 
identified  by  different  local  run  values,  they  can  be 
kept  distinct. 

All  values  of  state  variables  are  initially  empty.  The 
value  of  a  state  variable  is  computed  as  follows.  Sup¬ 
pose  that  at  time  T,  as  recorded  in  the  participant’s 
counter,  the  value  of  a  state  variable  S  is  I'.  If  a  rule 
fires  at  time  T  making  the  value  of  S  equal  to  Z,  then 
the  value  of  S  at  time  T  +1  is  Z.  If  no  such  rule  fires, 
then  the  value  of  S  at  time  T  +  1  remains  I'. 

Besides  describing  the  words  and  state  variable  val¬ 
ues  produced,  each  protocol  rule  also  includes  an  op¬ 
tional  event  statement.  The  event  statement  gives 
a  description  of  the  event  that  occurred  when  that 
rule  fired.  Each  event  statement  has  five  arguments. 
The  first  is  the  name  of  the  principal  to  which  the 
rule  applies  (this  user  can  be  the  intruder),  the  sec¬ 
ond  is  a  (possibly  empty)  list  of  other  principals 
who  may  be  involved  in  the  event,  the  third  is  the 
name  of  the  rule  that  produced  the  event,  the  fourth 
is  a  list  of  words  involved  in  the  event,  and  the 
fifth  is  the  round  number.  Thus,  for  example,  if 
we  have  a  rule  describing  a  server  sending  a  key  K 
to  a  principal  U  who  has  requested  it,  we  might 
attach  an  event  statement  such  as  event  (server , 
[U]  ,  server _sendkey,  [K]  ,  N) .  Event  statements 
are  used  in  defining  queries  that  the  user  will  present 
to  NPA. 

Note  that  it  is  up  to  the  writer  of  the  specification 
to  decide  what  words  are  to  be  included  in  the  event 
statement.  There  is  no  fixed  algorithm  for  doing  this; 
instead,  it  depends  on  what  types  of  queries  the  user 
thinks  he  or  she  will  be  likely  to  make. 

To  give  an  example  of  an  NPA  protocol  rule,  con¬ 
sider  the  following  hand-generated  rule,  which  de¬ 
scribes  the  first  step  in  the  Otway-Rees  protocol: 

Subroutine 

init_start(prin(A, honest) ,N,T)  : 
init_self  :=  prin(A, honest) , 
init_who  :=  prin(B,H), 
init_server  :=  server(S, honest) , 
init_sessid  := 

rand(ts(prin(A, honest) ,N,T) ,sessid) , 
init_nonce  := 

rand(ts(prin(A, honest) ,N,T) , nonce) , 
init_masterkey  := 

keytable(prin(A, honest)) : 
send  msg  ({init_self } , {init_who} , 

[{init_sessid} , {init_self } , 

{init_who} , 
e({init_masterkey} , 

({init_nonce} , {init_sessid} , 


init_self } , {init_who}) )] ,N) : 
event (pr in (A, honest) , [{init_who}] , 

init_start , 

[{init_nonce} , {init_sessid}] ,N) . 

NPA  protocol  rules  can  also  call  other  rules  as  sub¬ 
routines.  This  is  done  by  listing  the  names  of  the 
subroutines  called  in  the  order  which  they  are  called. 
Thus,  for  example,  the  sequence  of  actions  performed 
by  the  server  in  the  Otway-Rees  protocol  is  specified 
by  a  rule  that  calls  three  actions  as  subroutines,  as 
follows: 

Session  init_main(prin(A, honest) ,N,N) : 
init_start , 
init_accept , 
init_compromisekey . 

Besides  rules  describing  protocol  transitions,  an 
NPA  protocol  specification  also  contains  sections  de¬ 
scribing  which  words  are  known  initially  by  the  in¬ 
truder,  what  rewrite  rules  hold,  what  operations  (such 
as  encryption  or  decryption)  are  performed  on  words, 
and  which  of  these  operations  may  be  performed  by 
an  intruder.  These  last  are  used  by  NPA  to  build  a 
state  machine  model  of  the  intruder. 

The  user  is  given  a  fair  amount  of  freedom  in  defin¬ 
ing  words.  However,  there  is  one  construct  that  MUST 
be  used  when  words  such  as  keys,  nonces,  etc.,  which 
must  be  random  or  pseudo-random,  are  defined.  This 
is  the  name-round-time-stamp:  ts(A,N,T) ,  where  A  is 
the  name  of  the  originator  of  the  word,  N  is  the  round 
during  which  it  was  generated,  and  T  is  the  time  at 
which  it  was  generated.  If  a  name-round-time-stamp 
appears  in  a  word,  it  is  guaranteed  to  be  different  from 
any  word  generated  by  any  other  party,  or  during  any 
other  round,  or  at  any  other  time. 

Another  construct  that  is  not  required,  but  is  rec¬ 
ommended,  is  the  use  of  the  honesty  variable.  A 
participant  in  a  protocol  can  have  an  honesty  vari¬ 
able  attached  to  its  name  that  can  be  set  either  to 
honest  or  dishonest.  For  example,  we  can  identify  a 
principal  by  principal(A,H) ,  where  A  is  the  princi¬ 
pal  ID,  and  H  is  set  equal  to  “honest”  or  “dishon¬ 
est”.  Honest  principals,  identified  as  principal  (A, 
honest),  are  assumed  to  follow  the  rules  of  the  pro¬ 
tocol  and  not  to  reveal  their  secrets  unless  the  pro¬ 
tocol  requires  it.  Dishonest  principals,  identified 
as  principal  (A,  dishonest) ,  are  assumed  to  be  in 
league  with  the  intruder  and  to  share  all  informa¬ 
tion  with  it.  Thus,  for  example,  if  master  keys  are 
identified  as  mskey(U),  where  U  is  a  principal  name, 
the  intruder  may  be  assumed  to  know  all  keys  of  the 


form  mskey (principal (A,  dishonest)).  Finally,  if 
an  honest  principal  receives  a  message  from  another 
principal,  it  will  not  know  whether  the  other  principal 
is  honest  or  dishonest;  when  an  honest  principal  re¬ 
ceives  a  message  from  another  principal  B ,  that  prin¬ 
cipal  will  be  represented  by  the  name  principal  (B, 
H) ,  where  H  is  an  uninstantiated  variable. 

There  are  some  important  differences  between 
CAPSL  and  the  NPA  language.  In  CAPSL,  actions 
of  parties  upon  receiving  messages  are  usually  left  im¬ 
plicit.  In  the  NPA  language,  they  must  be  made  ex¬ 
plicit.  Moreover,  in  CAPSL,  properties  such  as  fresh¬ 
ness,  uniqueness,  randomness,  etc.  are  declared  ini¬ 
tially.  In  the  NPA  language,  they  must  be  guaranteed 
by  the  use  of  name-round-time  stamps.  In  CAPSL, 
intruder  actions  and  knowledge  are  left  unspecified. 
In  the  NPA  language,  they  are  defined,  if  only  implic¬ 
itly.  Finally,  CAPSL  has  nothing  resembling  the  event 
statement  used  in  the  NPA  language.  Thus,  a  CAPSL- 
to-NPA  translator  has  a  large  amount  of  information 
to  generate. 

4  The  Translator 

The  CAPSL  translator  inputs  CAPSL  specifica¬ 
tions  and  outputs  specifications  in  different,  user- 
selected,  forms  suitable  for  different  types  of  use.  This 
section  describes  the  overall  structure  of  the  CAPSL 
translator  and  how  it  produces  its  outputs. 

The  current  version  of  the  translator  produces  out¬ 
puts  in  the  following  three  forms,  of  which  only  the 
first  is  used  in  the  current  effort: 

•  specifications  for  NPA; 

•  specifications  for  a  preliminary  version  of  the  Pro¬ 
tocol  Description  Logic  (PDL),  a  Higher  Order 
Logic  (HOL)  theory  of  authentication  protocols 
and  protocol  failure;  and 

•  human-readable  descriptions  of  the  algorithms 
followed  by  the  processes  implementing  a  proto¬ 
col’s  roles. 

See  [3]  for  the  preliminary  version  of  PDL  used  by  the 
translator  and  [4]  for  a  later  version  of  PDL  intended 
to  formalize  new  CAPSL  capabilities. 

The  remainder  of  this  section  describes  the  CAPSL 
translator’s  structure  and  algorithms,  particularly  its 
algorithms  for  producing  NPA  specifications. 

4.1  Translator  Structure 

The  CAPSL  translator  is  a  flex/bison  applica¬ 
tion;  flex  and  bison  are  standard  compiler-writing 


tools,  available  from  the  Free  Software  Foundation,  for 
generating  lexical  analyzers  and  parsers,  respectively. 
The  translator  operates  in  three  stages: 

•  Stage  1:  Parse  the  CAPSL  specification,  along 
with  definitions  of  default  CAPSL  Abstract  Data 
Types,  and  create  corresponding  internal  data 
structures. 

•  Stage  2:  Compute  the  algorithms,  expressed  in 
further  internal  data  structures,  carried  out  by 
processes  performing  each  of  the  specified  proto¬ 
col’s  roles. 

•  Stage  3:  Produce  output  of  the  user-selected  type 
from  the  data  structures  computed  in  Stage  2. 

Detailed  descriptions  of  each  of  these  stages  follow. 

4.2  Stage  1 

Stage  1  first  internally  prepends  the  standard 
TYPESPEC  specifications  for  built-in  encryption  op¬ 
erators  to  an  input  CAPSL  specification  file,  then 
parses  the  augmented  file.  The  translator  produces 
internal  data  structures,  most  notably  a  symbol  table, 
that  describe  the  contents  of  the  augmented  file. 

The  entry  for  a  symbol  in  the  translator’s  symbol 
table  completely  defines  the  object  that  this  symbol 
names.  In  particular,  the  entry  for  a  protocol  identifier 
contains  lists  of  actions  that  describe  all  the  actions 
taken  in  following  the  protocol,  treating  these  actions 
as  if  they  were  always  sequential. 

In  addition  to  producing  the  symbol  table,  Stage  1 
identifies  syntactic  errors  and  some  semantic  errors  in 
the  CAPSL  specification  file,  particularly  type  incom¬ 
patibilities  and  symbols  that  are  used  before  they  are 
defined.  Stage  1  also  implements  syntactic  CAPSL  ca¬ 
pabilities  that  allow  symbols  to  rename  other  symbols, 
abbreviate  expressions,  and  represent  subprotocols. 

4.3  Stage  2 

Stage  2  expresses  the  algorithms  followed  by  the 
processes  performing  a  specified  protocol’s  roles  as 
lists  of  statements  in  a  simple,  unnamed,  C-like,  im¬ 
perative  programming  language.  Stage  2  expresses 
these  statement  lists  as  internal  data  structures;  Stage 
3  produces  text  output  of  the  user-selected  form  from 
these  data  structures.  Informal  descriptions  of  the  dif¬ 
ferent  statement  types  in  this  unnamed  internal  lan¬ 
guage,  and  their  meanings,  follow. 

In  these  descriptions,  a  slot  is  an  abstract  storage 
location  capable  of  holding  any  finite  amount  of  data 


of  any  type,  corresponding  roughly  to  a  CAPSL  vari¬ 
able.  An  expression  is  either  a  slot  name  or  a  term 
consisting  of  an  algorithm  name  applied  to  a  tuple 
of  expressions.  Distinct  processes’  slots  are  distinct, 
though  different  processes’  slots  can  have  the  same 
names. 

•  ASSIGN  <slot  name>  <expression>.  The  state¬ 
ment  replaces  the  current  contents  of  the  slot  with 
the  value  of  the  expression.  When  used  on  the 
right-hand  side  of  an  assignment  statement,  a  slot 
name  denotes  the  contents  of  this  slot. 

•  IF  <expression>  THEN  <statement  list  1> 
ELSE  <statement  list  2>.  If  the  expression  is 
true,  the  statement  does  the  first  statement  list, 
and  otherwise  it  does  the  second  statement  list. 

•  RECEIVE.  The  process  executing  a  RECEIVE  hangs 
until  a  message  addressed  to  this  process  arrives, 
then  stores  this  message  in  a  special  slot  named 
temp.  The  CAPSL  translator  assumes  that  ev¬ 
ery  message’s  first  two  fields  are  the  names  of  its 
purported  intended  recipient  and  its  purported 
sender. 

•  SEND  <expression  1>  Expression  2>.  The 
statement  sends  the  process  named  by  the  first 
expression  the  message  consisting  of  the  receiv¬ 
ing  process’  name,  the  sending  process’  name,  and 
the  value  of  the  second  expression. 

•  TEST  <expression>.  This  statement  evaluates 
the  expression,  and  if  it  is  true  does  nothing.  Oth¬ 
erwise,  it  raises  an  alarm  and  aborts  the  protocol. 

Although  this  unnamed  intermediate  language  exists 
only  internally  to  the  CAPSL  translator,  the  prelim¬ 
inary  version  of  PDL  gives  a  HOL  formalization  of 
it,  and  the  translator’s  “human-readable  description” 
output  is  essentially  a  textual  form  of  it. 

Stage  2  determines  the  initial  contents  of  each  pro¬ 
cesses’  slots  and  the  subsequent  computations  that 
each  process  performs.  The  essential  problems  it 
solves  are  interpreting  CAPSL  equalities  and  making 
CAPSL  default  actions  explicit. 

CAPSL  equalities  are  problematic  because  they  are 
sometimes  assignments  and  sometimes  equality  tests; 
further,  if  they  occur  between  concatenations,  they 
can  mean  multiple  assignments  or  equality  tests,  or 
mixtures  of  assignments  and  equality  tests.  CAPSL 
interprets  an  equality  as  a  test  if  both  the  values  set 
equal  are  defined,  and  interprets  it  as  an  assignment 
if  only  one  of  these  values  is  defined. 


Stage  2  enforces  that  all  distinct  computed  expres¬ 
sions  are  stored  in  distinct  slots,  maintains  lists  of 
slots  that  definitely,  possibly,  and  definitely  do  not 
have  assigned  values,  and  uses  these  lists  to  interpret 
CAPSL  equalities.  It  takes  intersections  and  unions 
of  these  lists  to  bound  the  effects  of  IF-THEN-ELSE 
statements.  Stage  2  also  uses  these  lists  to  determine 
if  a  slot’s  contents  might  be  used  before  they  are  de¬ 
fined,  and  if  so  raises  a  CAPSL  semantic  exception. 
Stage  2  also  raises  a  CAPSL  semantic  exception  if  an 
assignment  might  change  a  CONSTANT  value,  change  a 
non-temporary  slot  value,  or  invalidate  a  relationship 
given  by  a  DENOTES  statement. 

A  process  can  perform  CAPSL  default  actions 
whenever  it  receives  a  message  or  performs  an  as¬ 
signment  to  a  slot  whose  contents  it  had  not  yet  de¬ 
termined.  Stage  2  assumes  that  a  process  performs 
equality  tests  on  any  values  it  receives  that  the  pro¬ 
cess  already  holds.  Stage  2  further  assumes  that  a 
process  decrypts  any  encrypted  values  it  holds  that 
it  is  able  to  decrypt,  applies  the  inverses  of  functions 
to  any  values  it  holds  that  are  computed  with  these 
functions,  and  performs  equality  tests  on  any  values  it 
obtains  that  the  process  already  holds. 

4.4  Stage  3 

This  subsection  describes  the  portion  of  the  CAPSL 
translator’s  Stage  3  code  that  produces  output  for 
the  NPA.  The  remainder  of  this  subsection  will  use 
“Stage  3”  to  mean  “the  portion  of  the  translator’s 
Stage  3  code  that  produces  NPA  output”.  As  the 
previous  subsection  indicated,  the  translator’s  human- 
readable  and  PDL  outputs  are  straightforward  vari¬ 
ants  of  the  translator’s  internal  imperative  program¬ 
ming  language,  so  producing  them  is  much  simpler. 
The  essential  problem  solved  by  Stage  3  is  translating 
algorithms  in  a  C-like  imperative  programming  lan¬ 
guage  into  the  Prolog-based  specification  language  of 
NPA. 

Stage  3  first  checks  that  all  the  protocol’s  algo¬ 
rithms  are  ones  that  the  NPA  can  analyze.  It  raises 
a  semantic  error  if  an  algorithm  uses  any  associative 
operation  or  any  commutative  operation  that  is  not 
specifically  handled  by  NPA  rules. 

As  a  convenience  to  users,  Stage  3  checks  that  each 
function  symbol  or  operation  used  in  a  protocol  is  at 
least  mentioned  in  an  AXIOM  or  DENOTES  statement  for 
the  protocol,  and  prints  a  warning  that  there  will  be 
no  way  for  NPA  to  make  inferences  about  the  function 
symbol  or  operation  if  not. 

After  finding  all  the  identifiers  that  must  be  de¬ 
clared  in  the  NPA  translation  of  a  protocol’s  algo¬ 


rithms  —  a  complicated  process  that  involves  parti¬ 
tioning  the  protocol’s  algorithms  into  fragments  that 
are  expressible  as  NPA  subroutines  —  Stage  3  begins 
outputting  the  text  of  the  NPA  translation.  It  declares 
the  following  identifiers  specific  to  the  protocol,  along 
with  other,  protocol-independent,  declarations  needed 
by  NPA: 

•  event  names  naming  the  translation’s  Session 
and  Subroutine  elements; 

•  state  variable  names  giving  the  protocol’s  slots; 

•  variables  used  to  represent  the  possible  honesty 
values  of  the  processes  performing  the  protocol’s 
roles; 

•  two  time  variables  for  each  processe  playing  one 
of  the  protocol’s  roles  —  the  NPA  uses  one  time 
to  identify  sessions,  and  another  time  to  identify 
sequential  events  within  a  session; 

•  Prolog  variables  used  to  temporarily  store  ele¬ 
ments  of  received  or  assigned  lists  before  these 
elements  are  stored  in  state  variables; 

•  function  and  operation  symbols  specific  to  the 
protocol; 

•  RandID  atoms  specific  to  the  protocol. 

Stage  3  then  outputs  NPA  rewrite  and  commutativ¬ 
ity  rules,  rules  that  essentially  just  reformulate  defini¬ 
tions  in  the  CAPSL  default  type  specifications  giving 
properties  of  standard  functions  used  in  the  protocol. 

Stage  3  next  outputs  a  list  of  values  assumed  to  be 
known  to  an  attacker  trying  to  defeat  the  protocol.  It 
generates  this  list  by  examining  each  term  denoting 
a  value  used  in  the  protocol  and  computing  the  most 
general  form  of  this  term  that  will  be  known  to  an 
attacker,  assuming  that  the  attacker  knows  all  names, 
all  times,  all  public  keys,  and  all  information  known 
to  any  dishonest  protocol  process. 

Finally,  Stage  3  outputs  the  Session  and 
Subroutine  definitions  for  each  of  the  protocol’s  algo¬ 
rithms.  It  defines  each  Session  to  contain  assignment 
statements  that  compute  the  values  in  the  algorithm’s 
initialized  slots,  followed  by  calls  to  NPA  subroutines 
that  carry  out  the  various  NPA-expressible  parts  of 
the  algorithm.  It  expresses  each  if-then-else  statement 
as  an  NPA  subroutine  call  of  the  form  SI:  Or:  S2 
where  SI  is  a  subroutine  that  executes  only  if  the  con¬ 
dition  in  the  if-then-else  statement  is  true  and  S2  is  a 
subroutine  that  executes  only  if  the  condition  in  the 
if-then-else  statement  is  false. 


5  Results  of  Using  the  CAPSL-to- 
NPA  Translator 

We  tried  out  the  translator  on  a  number  of  dif¬ 
ferent  protocols,  but  wound  up  concentrating  on 
six:  Kerberos[18],  the  two  Needham-Schroeder  proto¬ 
cols  [17],  Otway- Rees[19],  Bellovin  and  Merritt’s  En¬ 
crypted  Key  Exchange  (EKH)[f.  and  a  fragment  of 
the  Secure  Socket  Layer  Protocol[21],  We  had  al¬ 
ready  developed  hand-generated  NPA  specifications 
of  Needham-Schroeder  public  key  and  the  Otway- Rees 
protocol  (two  rules  of  which  are  given  in  Section  4),  so 
we  found  these  useful  for  doing  comparisons  between 
translator  and  hand-generated  output. 

Somewhat  to  our  surprise,  we  found  the  translator 
output  very  similar  in  appearance  to  that  generated 
by  humans.  The  main  difference  was  that  state  vari¬ 
able  names,  which  were  generated  automatically,  were 
not  that  helpful  in  identifying  to  the  reader  that  part 
of  the  protocol  to  which  they  applied.  Also,  the  event 
statements,  which  contained  all  state  variables  used 
in  a  round,  were  considerably  more  bulky.  But  other 
than  that,  there  was  not  much  difference  between  the 
look  of  a  translator-  and  a  human-generated  specifica¬ 
tion. 

For  example,  consider  the  following  two  rules  in  the 
translation  of  the  CAPSL  specification  of  the  Otway- 
Rees  protocol.  The  first  rule,  a_raain,  describes  the 
order  in  which  the  initiator’s  rules  are  executed,  and 
also  defines  the  terms  that  are  generated  by  the  ini¬ 
tiator.  The  second,  a_sub_l  describes  the  initiator 
sending  the  first  message.  Thus  a_main  and  a_sub_l 
correspond,  respectively,  to  the  hand-generated  rules 
init_main  and  init_start  in  Section  3. 

Session  a_main(prin(Ua, honest) ,Tal,Tal) : 

Session  a_main(prin(Ua, honest) ,Tal,Tal) : 

a_A  :=  prin(Ua, honest) , 

a_B  :=  prin(Ub,Hb), 

a_KeA  :=  keytable(prin(Ua, honest)) , 

a_M  :=  freshf ield(ts (prin(Ua, honest) , 

Tal ,Tal) ,am) , 

a_Na  :=  newcryptof ield(ts (prin(Ua, honest) , 
Tal ,Tal) ,ana) : 
a_sub_l , 
a_sub_2 . 

Subroutine  a_sub_l (prin(Ua, honest) ,Tal,Ta2) : 
a_Kass  :=  {a_KeA}: 
send  msg({a_A} , {a_B} , 

[{a_M> , {a_A> , {a_B> , 
se({a_Kass} , 

({a_Na},{a_M},{a_A},{a_B}))] ,Tal) : 


event (prin(Ua, honest) , [{a_B}] ,a_sub_l, 

[{a_A} , {a_B} , {a_Kab} , {a_KeA} , 

{a_M} , {a_Na} , {a_seKacoNaKa}]  ,Tal) . 

Efficiency  was  another  concern.  There  were  two 
main  ways  that  a  translator-generated  protocol  dif¬ 
fered  from  a  human-generated  one.  One  was  that  the 
translator  often  broke  a  simple  state  transition  into 
several  subtransitions.  The  other  was  that  words  used 
in  a  protocol  were  always  created  at  the  beginning  of 
a  protocol  run  by  the  translator,  while  human  speci¬ 
fication  writer  could  specify  parties  as  creating  words 
any  time  before  they  were  used.  Thus,  for  exam¬ 
ple,  in  the  above  specification,  the  nonce  denoted  by 
freshf ield(ts (prin(Ua, honest) ,  Tal, Tal) ,am) 
is  generated  in  a_main,  while  in  the  hand-generated 
rules  given  in  Section  3  the  same  nonce,  denoted  by 
rand(ts(prin(A, honest) ,N,T) , nonce) is  generated 
in  the  second  rule,  init_start.  This  difference  tends 
to  make  the  hand-generated  specification  more  effi¬ 
cient,  for  the  following  reason:  the  Analyzer  includes 
a  mechanism  for  discarding  states  that  contain  name- 
time-stamp  words  that  are  used  be  before  they  were 
created.  Since  the  Analyzer  works  by  searching  back¬ 
wards,  these  types  of  unreachable  states  are  detected 
earlier  when  the  the  name-time-stamp  words  are  cre¬ 
ated  later  in  a  specification. 

We  expected  both  of  the  above  described  differences 
to  affect  efficiency.  Actually,  only  the  second  seems 
to.  When  we  used  the  NPA  to  process  queries  on 
the  translated  Needham-Schroeder  protocol,  we  found 
very  little  difference  in  efficiency  between  it  and  the 
human-generated  one.  However,  when  we  ran  the 
translated  Otway-Rees  protocol,  we  found  it  consid¬ 
erably  slower  than  the  human-generated  one.  When 
we  altered  the  specification  so  that  words  involving 
name-round-time  stamps  were  generated  immediately 
before  use,  though,  this  difference  in  efficiency  went 
away,  and  the  translated  specification  became  as  ef¬ 
ficient  as  the  hand-generated  one.  It  is  not  quite  as 
straightforward  for  the  translator  to  generate  words 
right  before  use  as  it  is  to  put  them  at  the  beginning 
of  the  protocol,  but,  given  the  dramatic  improvement 
in  efficency  it  brings,  we  think  that  this  change  is  well 
worth  implementing. 

Finally,  we  were  concerned  about  expressiveness. 
In  this,  we  had  mixed  results.  However,  the  problems 
we  have  encountered  have  shown  us  ways  in  which 
both  the  translator  and  CAPSL  can  be  improved.  The 
six  specifications  we  used  introduced  various  features. 
Kerberos  is  based  on  timestamps.  The  Otway-Rees, 
the  Needham-Schroeder  protocols,  and  Kerberos  make 
use  of  key  servers.  EKE  uses  the  Diffie-Hellman  pro- 


tocol,  a  protocol  with  commutativity  properties  that 
allowed  us  to  try  out  an  experimental  implementation 
of  commutativity  for  NPA.  SSL  is  a  complex  proto¬ 
col  with  several  options;  we  used  it  to  test  our  use  of 

IF-THEN-ELSE. 

The  first  problem  we  encountered  was  that  the 
translator  did  not  allow  for  comparisons  between  vari¬ 
ables  and  constants,  which  are  used  for  IF-conditions. 
A  mechanism  to  do  this  is  being  implemented. 

The  next  problem  we  encountered  was  that  we 
could  not  specify  any  assumptions  about  honesty.  In 
most  of  our  hand-generated  specification  of  server- 
assisted  protocols,  we  have  assumed  that  the  key 
server  is  always  honest;  clearly,  if  the  key  server  is  not 
honest  the  protocol  will  fail.  CAPSL  allowed  us  to 
make  no  such  distinction,  and  so  the  translator  gener¬ 
ated  both  honest  and  dishonest  key  servers.  However, 
this  does  not  appear  to  cause  a  serious  problem  in  ei¬ 
ther  efficiency  or  expressiveness:  the  user  can  simply 
specify  that  actions  must  involve  an  honest  key  server 
when  presenting  his  or  her  query. 

Another  problem  we  found  was  in  the  expression  of 
key  compromise.  At  the  beginning,  we  had  no  stan¬ 
dard  way  of  representing  key  compromise  in  Analyzer 
specifications,  and  no  way  of  recognizing  what  words 
should  be  vulnerable  to  compromise.  Since  then,  we 
have  worked  out  a  standard  representation  of  com¬ 
promise  and  a  standard  way  of  recognizing  vulnera¬ 
ble  words  in  a  CAPSL  specification.  The  vulnerable 
words  are  those  declared  to  be  SECRET  in  the  goals  sec¬ 
tion  (so  we  know  which  parties  are  supposed  to  possess 
them  as  secrets),  and  FRESH  (so  they  are  relevant  only 
to  a  single  session).  It  should  then  be  simple  to  gen¬ 
erate  compromise  transitions  for  the  parties  who  are 
intended  to  possess  the  secrets.  We  do  not  anticipate 
any  problem  in  having  the  translator  recognize  these 
words  and  append  compromise  transitions  to  the  end 
of  a  specification. 

6  Conclusions  and  Lessons 

We  made  a  number  of  changes  to  CAPSL  as  a 
result  of  this  experience  of  building  an  interface  to 
NPA.  Some  changes  were  made  immediately  to  help 
us  through  the  translator  project,  and  others  had  their 
impact  in  the  form  of  more  radical  language  revisions 
that  are  still  in  progress.  The  deeper  changes  con¬ 
cern  the  design  and  use  of  the  specification  units  we 
have  not  discussed  here,  type  specifications  and  envi¬ 
ronments. 

The  immediate  changes  included  the  introduction 
of  the  LONGTERM  property  for  a  variable,  meaning  that 


it  has  the  same  value  in  several  sessions.  Also,  we 
added  a  security  goal  SESSION_SECRET,  which  differs 
from  SECRET  in  that  the  secret  item  is  no  longer  con¬ 
sidered  sensitive  after  a  session  has  terminated. 

Many  needs  for  specifying  a  protocol’s  environment, 
including  different  styles  for  giving  principals’  roles, 
were  worked  out  during  design  discussions  for  future 
versions  of  CAPSL.  We  found,  for  example,  that  some¬ 
times  it  is  desirable  to  consider  “what-if”  scenarios  in 
which  the  intruder  is  assumed  to  possess  secret  keys  or 
other  specific  items  that  would  normally  not  be  avail¬ 
able.  An  ATTACKER_HOLDS  section  was  added  for  this 
purpose. 

Some  aspects  of  the  language  were  found  to  be  awk¬ 
ward  or  inadequate,  and  while  no  changes  in  them 
were  made  immediately,  these  discoveries  had  an  effect 
on  the  new  design  in  progress.  One  problem  is  how  to 
indicate  whether  functions  declared  in  type  specifica¬ 
tions  are  available  for  use  by  the  intruder:  Encryption 
functions  are  usually  assumed  to  be  known  to  the  in¬ 
truder,  but  a  function  that  produces  the  secret  key  of 
a  principal  is  also  declared  in  a  type  specification,  and 
the  intruder  cannot  evaluate  it  to  obtain  secret  keys. 
A  property  PRIVATE  for  these  functions  was  planned. 

The  choice  of  keywords  and  other  details  of  the  syn¬ 
tax  can  probably  be  improved.  It  has  been  pointed  out 
that  certain  keywords  are  overloaded.  The  true  mean¬ 
ing  of  VARIABLES  and  CONSTANTS  in  a  protocol  defini¬ 
tion,  for  example,  is  different  enough  from  both  pro¬ 
gramming  language  concepts  and  abstract  datatype 
concepts  that  other  keywords  might  be  more  appropri¬ 
ate;  and  the  DENOTES  section  is  used  for  two  or  three 
conceptually  different  purposes. 

The  language  is  still  evolving,  with  the  help  of  con¬ 
tributions  from  the  community  of  researchers.  The 
current  version,  documented  on  the  web  site  [5],  re¬ 
flects  the  needs  and  insights  that  were  manifested  dur¬ 
ing  this  effort. 
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